Distributed Network Security

IP-based networks form the base of todays communication infrastructure. The interconnection of formerly isolated networks brings up severe security issues. The standard approach, to protect the own network from abuse, is the usage of filter mechanisms at the border to the foreign network. The raising complexity of protocols and the use of encryption techniques render most of these borderoriented systems useless, as their are not able to track or analyze the transfered data. The approach discussed in this article splits into three parts – first we invent distributed sensors which enlarge the amount of data available for analysis by accessing information directly at its source. To integrate these into the classic border oriented system we create an abstract interface and management system, based on the Common Information Model. Finally we will divide the management system itself into independent components, distribute them over the network and gain significant increase of performance. 1. Topical security systems The interconnection of formerly private and isolated communication networks enables new forms of services and applications, but brings also new threats and the need for appropriate defense mechanisms. Until today, most networks are secured by firewalls which apply IP-packet-filtering at the interface between the internal and the external network. This raises two major problems: First, as traffic is allowed or denied only based on IP-packet information, it is impossible to associate traffic to certain applications or process on the client machines in the internal network. If a client is infected by malicious software, collecting and sending information to an outside attacker e.g. through the standard HTTP port, the firewall may identify this as allowed traffic to a webpage server and hence allows the packets to leave the network. On the other hand there are applications, especially for streaming media, which do not follow the classic client-server-model, where connections are always established by the client using well-known determined resources but use bidirectional peer-to-peer connections instead. They usually allocate these resources randomly, making it impossible to define an ip-based rule set without either understanding the protocol stream or gathering additional information on the client. In some setups the problems stated above can be solved when analyzing the payload of the passing IPpackets. There are several different techniques available in the market, all of them basically do the same – they re-assemble the extracted payload to the originating higher-level protocol and apply filter rules to it. This method implies two things. First – the system must implement the specification of the watched protocol. In theory this problem can be solved, but in practice, many specifications are not available to the public and the number of different protocols raises every day. Additionally, as there is no standard for such filters, every system-vendor must build the filters for his own product. As soon as the payload is encrypted, there is no chance to gather information from the stream. Due to these two problems, it is impossible to build a reliable and secure firewall system, when only inspecting traffic at the time it crosses the border. The only place where we can gather more data, is the source of the traffic, so we introduced a sensor on the endpoint of the network – the client-computer. There are some commercial products available, that implement some of the techniques discussed in this article. All of them use proprietary control streams and interfaces so it is impossible to combine different products. 2. Client-side information gathering The client-computer is the source of all traffic going through the network and crossing the border gateway. The most important information regarding our security system is the process that initiates the network packet. On a modern multi-task, multi-user operating system like Linux oder MS Windows a process has two significant properties. Each process is associated with a system user, who is the owner of the process and herewith creator and owner of the network packet. The second attribute we can assign to a process is the “program” that is executed by this process. To give an example – we can state that the connection to the webserver from “amazon.com” was triggered by the user “john” using the program located at “/usr/local/mozilla/mozilla-bin”. This information is very valuable for the security system. The program information tells us, that the requesting application is a legal webbrowser and not some malware, that tries to send out or download data. With the owner attribute we can of course simply check, if the user is allowed to use the resources, but we can do more – if a lot of process are started on different machines all over the network from the same user account, it is likely that the password of the user was compromised and someone is abusing this to gain access to restricted resources. 2.1. Technical prerequisites All research within our group is based on the CIM Model [1] and uses the WBEM server from Sun Microsystems [2], which is written in Java. The decision for this WBEM implementation was taken, because we wanted a portable solution for at least the two operating systems that we are using in our group – Linux and Windows. Besides the portability the security aspect of the virtual machine concept was another reason for our decision. To keep this advantages we wrote all other components in Java, too and tried to use the “Java Native Interface” Standard [3] for operating system dependent bindings.